Concept

What is a Skill?

A skill is a saved prompt template that encodes a specific type of thinking. You write it once, reuse it across projects, and share it across your team.

01
The Skill
A structured prompt
Written once by someone who knows the domain. It tells Claude exactly what to look for, how to weigh findings, and what format to produce — every single time.
+
02
Your Input
Any raw material
A PRD, a stakeholder interview, a prototype, a user story. The skill wraps around it and tells Claude how to read it through the right lens.
03
Structured Output
Consistent, traceable analysis
The same six sections, every time, with findings tied to specific requirement IDs — so anyone on the team knows exactly what they're getting and how to act on it.
Reusable
Run it on every PRD. The prompt doesn't change — only the input does. Each output becomes a reference for the next project.
Shareable
Save it to a Claude Project. Every team member gets the same analysis quality without writing a single prompt themselves.
Composable
Skills can be chained. The UX analysis becomes the brief for a prototyping prompt. The prototype output feeds a spec review skill.
Evolvable
Modify the prompt as the team learns. Add a compliance section, tune the output format, encode more of your specific domain expertise over time.
Tips & Tricks

Version shared skills like code. Keep one strong sample input, one weak sample input, and the output shape you expect. When you revise the skill, rerun those checks before the team adopts the new version.

Best Practices

Writing skills that hold up

Four patterns used in this skill that make the difference between a prompt that works once and one that works reliably across every PRD.

01
Use // for meta-instructions
Prefixing instructions with // signals to Claude that these are rules governing how to run the skill — not content to reproduce in the output. Claude reads comment-style syntax as directives, not prose.
// Do not summarise the PRD. // Analyse it.
02
Constrain the output shape
Without length constraints, Claude over-produces — burying important findings in noise. Without a floor, it can be too brief on sections that need depth. Specify both the format and the count for every output section.
// Sections 1–5: 3–6 findings each. // Section 6: exactly 2–3 principles.
03
Force traceability
Explicitly require Claude to cite source IDs. Without this instruction, findings are vague and unactionable — you can't tell what requirement triggered them or who to take them to. Named references make every finding a starting point for a conversation.
// Reference requirement IDs // (e.g. F-11, AC-03) wherever relevant.
04
Override the default behavior
Claude's instinct with a long document is to summarise it first, then comment. That's the wrong behavior for a skill. Name what you don't want, not just what you do — the explicit prohibition is what breaks the pattern.
// Prioritise by design impact, // not document order.
05
Name the role, not just the task
Opening with "You are a senior UX designer" isn't decoration — it activates a different reasoning frame than a generic prompt. Claude applies domain-appropriate standards, makes judgment calls the way that role would, and flags things that role would care about.
You are a senior UX designer reviewing a PRD.
06
Encode the output format explicitly
Don't describe what you want — show it. Specifying the exact format for each finding (name → requirement ID → implication) means every output has the same structure, making it scannable and usable without reformatting.
Format: [Gap name] → [Req ID] → [What's needed]
💬
You don't have to write Skills from scratch
Use Claude as a thinking partner to draft and refine your Skill before you save it. Describe the analysis you want to run, the output structure you need, and any constraints — then ask Claude to turn that into a properly formatted Skill. Iterate in conversation until it does exactly what you want, then save it. The same approach works for Figma Make prompts, design briefs, and any other reusable template: start with a conversation, not a blank page.
Output

What the skill produces

Six structured sections, each targeting a different failure mode that PRDs commonly miss. Claude references specific requirement IDs throughout so every finding is traceable.

1
UX Gaps
Requirements that exist in the PRD but have no design guidance — where decisions are being deferred to the designer without the information needed to make them.
2
Missing States
Edge cases the PRD doesn't specify: empty states, loading states, error states, zero-data views, permission conflicts, and data-freshness scenarios.
3
Interaction Ambiguities
'What' is described but not 'how'. "User can filter" — but by what, in what order, with what feedback, and what happens to the URL state?
4
Accessibility Flags
Requirements that will be hard to meet accessibly as written — surfaced before design begins, not after an audit catches them.
5
Open Design Questions
Questions the designer needs answered before wireframing can begin — extracted automatically so you go into the first design review prepared.
6
Suggested UX Principles
2–3 design principles that should guide the feature, derived from the user roles, workflow context, and constraints described in the PRD.
The Skill

Copy this prompt

Paste this into Claude.ai (or any Claude interface) before your PRD text.

PRD UX Analysis Skill — v1.0
// PRD UX Analysis Skill
// Use: Paste this before any PRD to surface UX gaps before design begins.

You are a senior UX designer reviewing a product requirements document.
Analyse the PRD below and produce a structured UX Analysis covering six sections:

1. UX GAPS
   Requirements that exist in the PRD but have no design guidance — where a design
   decision is being deferred to the designer without the information to make it.
   For each gap: name it, quote the relevant requirement ID, and describe what
   the designer needs to know before they can make this decision.

2. MISSING STATES
   Edge cases and states the PRD does not specify. For each:
   — Empty state (no data, first use, filtered to zero results)
   — Error state (API failure, sync failure, permission error)
   — Loading state (skeleton, progressive disclosure, timeout)
   — Zero-data state (newly created trial with no patients yet)
   — Permission conflict state (role sees partial data)
   Be specific about which features or screens each missing state applies to.

3. INTERACTION AMBIGUITIES
   Places where the PRD describes WHAT happens but not HOW.
   For each: quote the requirement, describe what is underspecified
   (trigger, feedback, transition, error handling, keyboard behaviour).
   Example: "F-14 says 'dropdown multi-select' but doesn't specify:
   does applying a filter update the table immediately or require a button press?"

4. ACCESSIBILITY FLAGS
   Requirements that are likely to be hard to meet accessibly as written.
   Reference WCAG 2.1 AA where relevant. Flag:
   — Colour-only status indicators without icon or text fallback
   — Interactive elements without specified keyboard navigation
   — Dynamic content updates without specified ARIA live region behaviour
   — Touch target size concerns for dense data tables

5. OPEN DESIGN QUESTIONS
   Questions the designer needs answered before wireframing begins.
   Format each as: [QUESTION] → [Why it matters for design] → [Who owns the answer]
   Prioritise by design impact. List no more than 8.

6. SUGGESTED UX PRINCIPLES
   Based on the user roles, workflow context, and constraints in this PRD,
   suggest 2–3 design principles that should guide this feature.
   Format: [Principle name]: [One sentence description] — [One concrete implication]

// Instructions:
// — Be specific. Reference requirement IDs (e.g. F-11, AC-03) wherever relevant.
// — Prioritise findings by design impact, not document order.
// — Sections 1–5 should have 3–6 findings each. Section 6 should have exactly 2–3 principles.
// — Do not summarise the PRD. Analyse it.
    
Usage

How to run the skill

Three ways to use it, depending on which tool you're in. The output is identical — the tool choice depends on what you want to do with it next.

No PRD? Start here.
Use the example product interview transcript to practice running the skill before applying it to your own work.
View example transcript →
1

Claude.ai — simplest, works for everyone

Open claude.ai. Start a new conversation. Copy the prompt above → paste it → then paste your PRD below it → hit Enter. Claude will produce the full six-section analysis. Use this when you just need the analysis as a document to read and act on.

2

Claude Projects — for team reuse and shared context

Save the skill prompt to a Claude Project alongside your design system docs, brand guidelines, and previous analyses. Now every team member who opens that Project gets Claude pre-loaded with your full design context. Ask: "Run the UX Analysis skill on the enrollment PRD" and it already knows your system.

3

Cursor + Claude Code — when you want to act on the analysis immediately

Open the PRD file in Cursor. Type @PRD_Patient_Enrollment_Table.docx to attach it. Paste the skill prompt into the chat. The analysis will appear inline. Then immediately follow up: "Now generate a prototype that addresses the top 3 UX gaps you just identified." This turns analysis into design in one continuous session.

4

Claude Design — when analysis drives the prototype

Paste the skill prompt into Claude Design followed by the PRD. After the analysis appears, follow up: "Based on the UX gaps you identified, design the loan application review table with those gaps resolved." The analysis and the prototype happen in the same canvas — no copy-pasting between tools.

Creating

Build your own skill

In this workshop, a "skill" is a reusable prompt saved to a Claude Project — not the Claude Code developer feature. Here's how to go from idea to team-ready skill in a single conversation.

Use this to kick off any new skill — fill in the brackets and paste it into Claude:
Claude already knows how to write a well-structured skill prompt. You just need to give it the job description.
Skill-writing starter prompt
I want to create a reusable skill — a prompt template for a specific type of analysis.

Goal:         [what you want the skill to do — one sentence]
Input type:   [what you'll paste in — PRD, transcript, prototype HTML, spec doc]
Output:       [list the sections or findings you need]
Audience:     [who reads the output and what they do next]
Constraints:  [length, format, traceability, anything else]

Write this as a structured skill prompt. Use // for meta-instructions,
open with a role definition, name each output section explicitly with a
count range for findings, include an example format for each finding type,
and close with constraints as // comments. Make it ready to copy and paste.
Phase 1
Draft it in conversation
1

Describe the job — not the syntax

Open a new Claude.ai conversation. Explain the analysis you want to run: what input you'll paste in, what you need back, who reads the output, and what they do with it. Claude will ask clarifying questions — answer them. The goal of this turn is to get the logic right, not the structure. Don't think about prompt format yet.

2

Ask Claude to write the first draft

Once you've described the job, paste the starter prompt above into the same conversation. Claude already has your context from step 1 — the starter prompt tells it the structure to apply: role definition, // meta-instructions, named output sections with count ranges, and a format example for each finding type. It will produce a complete, copy-pasteable skill in one turn.

3

Test with real input, iterate in the same conversation

Open a new Claude.ai tab. Paste the draft skill + a real input document. Read the output critically against what you expected: Is the format right? Are findings specific or vague? Is a section missing? Is it too long? Go back to your drafting conversation — don't start a new one — and tell Claude exactly what to change. Two or three rounds is typical before a skill produces consistently good output.

Phase 2
Save it to Claude Projects
4

Paste the skill into Project Instructions

In Claude.ai, open (or create) the Project you want to share the skill in. Open the project settings and paste the finished skill into the Project Instructions field. Every conversation opened in that project will now have the skill active — team members paste their input and run the analysis without ever touching the prompt text.

5

Invite your team and leave a header comment

Invite team members to the project. Add a short // comment at the top of your instructions — one or two lines describing what the skill does, what input it expects, and what format it produces. Future maintainers (including you, six months from now) will thank you. When the skill needs updating, edit the project instructions directly — the change is live for everyone immediately.

💡
You don't need to start from blank
The PRD UX Analysis skill on this page is a working example you can adapt. Instead of writing from scratch, tell Claude: "Here's an existing skill I want to modify for [different input type / different output / different domain]. Keep the structure, change the analysis sections to cover [X]." Adapting a working skill is faster than building from a blank description every time.
Variations

Adapt the skill for different contexts

The base skill works for any PRD. These variations tune it for specific research and design scenarios.

User Research
Interview synthesis → requirements
Replace the PRD with a stakeholder interview transcript. Prepend this modifier before the skill prompt:
The following is a stakeholder interview transcript, not a PRD. Extract implied requirements, then run the UX Analysis on what you extracted. Flag where requirements are inferred vs. explicitly stated.
Design Review
Prototype analysis → evolved spec
Feed a working prototype HTML file to Cursor and prepend this modifier:
The following is a working prototype HTML file, not a PRD. Analyse it as a UX artefact: what design decisions were made, which should be locked in, which should be revisited, and what requirements appear to be missing from the original spec.
Financial / Regulated
Add SOC 2 / PCI-DSS compliance lens
For financial monitoring features, add a seventh section after Section 6:
7. REGULATORY DESIGN IMPLICATIONS: For each requirement, identify design decisions driven by SOC 2 Type II, PCI-DSS Level 1, or data privacy compliance. Flag where compliance requirements create UX constraints, and where those constraints conflict with usability best practices.
Feasibility
Early feasibility study screen analysis
For Sam's feasibility study work, replace Section 6 with this:
6. USER BURDEN ASSESSMENT: For each data collection requirement, assess the cognitive and time burden on end users. Flag where requirements create friction that could affect data quality, completion rates, or user dropout.
Extending the practice

Building a shared knowledge base

The skill becomes more powerful when the outputs accumulate. Here's how to build a knowledge base that amplifies everyone's work.

📁
Capture outputs
Every UX analysis, prototype, and evolved spec goes into a shared folder. Name files consistently: [Feature]_UX_Analysis_[date].md so they're searchable.
🧠
Claude Projects
Add your key docs to a Claude Project. Every team member gets Claude pre-loaded with your design context, past analyses, and design system rules.
Encode expertise as skills
Custom skills like this one encode team expertise and make it reusable. Each skill is a documented decision about how this team works — a living standard.
🔄
Close the loop
PRD → UX analysis → prototype → evolved spec → updated PRD. Each cycle, the knowledge base gets richer and the next project starts from a higher baseline.
Team prompt library — start here
After today's session, start a shared Claude Project called "UX Design Team — AI Skills". Add: this PRD UX Analysis skill · the prototype prompts from the workshop · your design system tokens · previous analysis outputs. Any team member who opens that Project gets Claude with full context. Alex owns this. Goal: have it running by end of week 2.
SDLC Context

Where this fits in the full pipeline.

Phase 00 — UX Discovery. Design exploration and prototyping anchor the SDLC before requirements are formalized.

Phase 00 — UX Discovery
AI-Powered SDLC pipeline diagram with Phase 00 UX Discovery highlighted.

Scroll right to see full pipeline →